Devices, such as mobile phones, desktop computers, laptops, tablets, and so on, may have their security controlled by an organization to ensure that the devices comply with the policies of the organization. For example, a company may control the security of mobile phones that its employees use to conduct business to ensure that sensitive information of the organization is not compromised. An organization may employ a policy source (e.g., a program executing on a server) to manage the policies of the devices. The policy sources may include a mobile device management (“MDM”) system, Microsoft's Group Policy, Microsoft's System Center Configuration Manager, messaging servers (e.g., to synchronize emails, contacts, calendars, tasks, and notes), and so on. When a device enrolls with a policy source, the policy source provides to the device policy information for controlling the device. The policy information may include, for example, password requirements (e.g., eight characters and at least one number and one letter), encryption requirements (e.g., encrypt all emails stored on the computing device), device lock requirements (e.g., lock device after 10 minutes of inactivity), email content requirements (e.g., add a legal notice to all emails), access control rights (e.g., administrator or user privilege), and so on. A program executing on a device ensures that the device operates in accordance with its policy information to ensure compliance with the policies of the organization.
The policies of some policy sources implement application locking and electronic data protection. With application locking, a programming executing on a device applies rules of a policy to determine whether an application can execute on the device. For example, a rule may specify that certain applications are prohibited from executing or that certain users are prohibited from running certain applications. With electronic data protection, a program executing on a device controls the data that the device can access. For example, an application provided by an organization may be allowed to access data of the organization, but no other application may be allowed to access the data of the organization.
When an application is to be executed, a process is created and control is passed to security code to set the security for the process based on the policy of the application. The security code, which may execute in a high privilege mode (e.g., kernel mode), retrieves the policy information for the application, creates a security token, and provides the security token to the process. The security token contains security information derived from the policy information and may be signed by the security code. When the process executing the application requests a service of a service provider (e.g., access to a file of a file system), the process provides the security token to the service provider as evidence of the policy information for the process. The service provider checks the security information of the security token to ensure that the requested service is allowed by the security information. If so, the service provider provides the service. If not, the service provider does not provide the service.
From time to time, the policy of an organization changes. For example, an organization may allow an application to access all the data of the organization regardless of the user who runs the application. The organization may, however, decide that access by some users should be restricted to only certain data of the organization. To implement such a change in policy, new policy information is distributed to the devices of the organization. The existing processes of the devices, however, have security tokens created based on the old policy information. To ensure that the current policy is being enforced on each device, the organization may require each device to be rebooted so that any process that has a security token based on the old policy information is terminated and any new process will have a security token based on the new policy information. The forcing of each device to reboot provides a less than optimal user experience. For example, a group of users may be in a collaboration session when their devices are rebooted. After each device is rebooted, the users would then need to rejoin a new collaboration session to continue where they left off before the rebooting.